perhaps just set it as an env (in the job scope, or top-level)...?

Is there another way to set an env variable? I thought this is how you do it

The way you did it I usually use when I want to dynamically set something within the workflow.

If more of a static var is required, I usually use:

env:
  BUILD_DIR : "${{github.workspace}}/build"
  INSTALL_DIR: "${{github.workspace}}/build/install"

e.g. in UMF workflow:
https://github.com/oneapi-src/unified-memory-framework/blob/main/.github/workflows/nightly.yml#L14-L16

it will work in both "job" and "global" scope

Isn't this defining the env variables for a single step only? i.e. variables defined this way do not propagate across steps

I use the variable again in actions/checkout call here

as I mentioned, you can set it up in "job" and/or "global" scope - see my example above set up for global scope

I think, setting it up for step scope is only possible if you use with clause (e.g. for running reusable workflow or an action)

my note on this change - while it seems convenient, I can see on my PC, that repo intel/llvm-ci-perf-results is ~600MB - this will be extra MBs added to intel/llvm repo, which is already quite big - just to consider

@ianayl would it be possible to compress the benchmarking data before pushing it to intel/llvm ?

In theory yes, but only the archived data. I think we'll need to have a conversation on this: it might even be reasonable to delete horribly outdated data.

We could also try moving archived data to intel/llvm-ci-perf-results, but alas that'll mean we need to keep an updated bot user token again for the repository.

Do github repositories have a max storage quota?

Do github repositories have a max storage quota?

https://docs.github.com/en/repositories/creating-and-managing-repositories/repository-limits#repository-size

we'll need to have a conversation on this

I think we should have that conversation before merging this PR. Currently, the size of intel/llvm-ci-perf-results is ~600MB, but, if unchecked the size will increase further.

In theory yes, but only the archived data. I think we'll need to have a conversation on this: it might even be reasonable to delete horribly outdated data.

Compressing results files gives ~190MB out of 320M, so I think it is better to just remove outdated data. We have data starting at March'25.

How many months of data do wee need to keep. 6? In this case we will have data staring from 15th April today. The rest will be in git history, hopefully well compressed.

We could also try moving archived data to intel/llvm-ci-perf-results, but alas that'll mean we need to keep an updated bot user token again for the repository.

If we go this way, we can archive e.g. once every second week, or something, and make a PR instead of pushing